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one must contact the certificate authority for this information a certificate would be revoked
if it was legitimately issued but later compromised or suspected of being compromised
it is because of this lack of a good revocation mechanism that short expiration times on
certificates are encouraged part of the information embedded in the fields in a
digital certificate is the validity time there's a start date and an end date for when this
certificate is valid it shouldn't be used before the start date and it shouldn't be trusted after
the end date this applies to ca routes as well as service certificates now it's not a huge deal
if a service certificate gets compromised or expires you reissue a new one but with root
certificates the issue is much more important because there is a lot of a lot of trust put in
the root certificates and
the compromise of a root certificate affects a large number of service certificates
if the compromise was of a leading ca like verisign the results would be devastating
several years ago the certificate authority thought lost a good number of customers when
its root certificate expired expirations are healthy the longer a key is in existence
the greater the chances that it will be compromised unfortunately thoughts customers saw this
as a hindrance to their customers for it was and a lot of them moved off to verisign
when you try to go to a website that has a legitimate certificate issued
by a route that's been expired scary browser messages pop up again users don't like that
their sign was quick to capitalize on thought's mistake
verisign in turn had the same problem at the end of 1999 when their root certificates expired
the fact that it was at the end of 99 however led a lot of people to believe it was a y2k problem
and they were more forgiving or verison as a better marketing spin machine remember the general public
expected their refrigerators to stop working as soon as the year 2000 came around so it wasn't
it wasn't hard to get them to forgive that thoughts expiration time was perhaps a little too
short but now if you look at your browser and the root certificates most of them expire between 2050
and 2020. thoughts expire in 2020 some of verisigns expire in 2028
do you plan to be using internet explorer 5.5 in the year 2028
these certificates have such a long lifetime that they might as well have no expiration at all
the trust process involving cas is riddled with potential pitfalls
one assumption we all make is that the ca will actually do its job
it's a reasonable assumption we expect them to verify that the entity requesting the certificate
is actually authorized to make that request recently microsoft got some bad press when
two digital certificates were issued in its name to an imposter i dislike microsoft as much as the
next guy but in this case i had to feel bad for them the blame here lies with verisign
who fell victim to a social engineering attack they issue hundreds of thousands of certificates
it's bound to have happened
but given the fact that vera sign can make mistakes
do you really want to rely on it blindly for assurance that sites you're visiting are
legitimate or is the threat itself so minimal that they're assigned or other cas are nearly
irrelevant users should be accustomed to examining website certificates before transmitting the
sensitive data the information they are
submitting is sufficiently sensitive, then this inconvenience is warranted. If not, then
the CA isn't needed at all. But isn't a CA necessary for SSL? The CAs would like you
to believe that. But as I previously stated, the encryption is handled by the software
running on the web server and the software that comes built into your browser. So, how does a
website admin get an SSL certificate, if not through a CA? Most SSL software allows the
generation of self-signed X.509 certificates. In this case, all the certificate information is
signed by the key of the web server, the key that's actually embedded in the certificate. There
is no chain, no root certificate. You are trusting that the certificate presented to you belongs
to the website owner. This will set off alarms in the client browser. Unfortunately, many people
would rather use no encryption at all, and thus receive no warning about invalid site certificates,
than trust a self-signed certificate. This is foolish. When a browser warns you about a
quote-unquote untrusted certificate, it isn't saying that the certificate is one you should not
trust. It is asking you if you wish to trust the certificate, and it asks you this on a case-by-case
basis.
Users should become accustomed to approving individual self-signed certificates. The dangers of
submitting information in the clear, without any encryption, are rather high, for it takes little
effort to set up a passive network sniffer if you have access to part of the network that the
information is traveling over. Passive attacks are relatively low risk to the attacker, and they are
generally undetectable. Passive attacks are the main threat to a compromise of privacy while
communication is occurring.
Though it's not always a good idea to have a passive network sniffer, it is a good idea to have a
passive network sniffer, though it should be noted that most e-commerce server compromises that
result in loss of customer data, credit card information, etc., are attacks against the databases
that store this information, for the payout is much greater. The attacker obtains a large number
of credit cards at once from the customer database server, rather than stealing them individually
over the wire. Most of the attacks against data that is being transferred will be attacks against
data sent in the clear. Most of the attacks against data that is being transferred will be attacks against
cybersecurity. They are passive attacks, and most will be opportunistic. If encryption is being used,
the attackers will not attempt to defeat it. Instead they'll seek out a different, easier target.
SSL is very good at preventing such attacks. It does a poor job of protecting against the remaining
small minority of threats. But these attacks are difficult to execute. If the attacker is determined
enough to attempt a more sophisticated attack, the use of a CA will only provide a speed bump, not a barrier.
So, SSL should be used for all user submissions to websites where the information being sent
is sensitive, regardless of the origin or issuer of the site certificate, unless the
site is clearly bogus.
If the website administrator can't afford the CA's fees, he or she should use self-signed
certificates.
Users should become accustomed to approving certificates on an individual basis and shouldn't
allow the browser warning messages to scare them.
One of the difficulties with that is that many administrators aren't aware of how to
generate self-signed certificates.
They like the ease and convenience of the certificate ordering process that commercial
CA's provide, and they don't wish to learn how to make their own certificates, or they
don't have their own time.
The FreeCert project is an attempt at a non-commercialization.
Our main goal is to provide certificates to sites whose administrators wish to use SSL,
but that desire is not an overwhelming need.
They don't have the time or ability to learn how to generate their own certificates, and
don't have the incentive or the budget to purchase a costly SSL certificate from a commercial
vendor.
Our main target audience is small businesses, individuals, and non-profit organizations,
though anyone is welcome to request a certificate.
We should be online within the next month and a half.
Initially, FreeCert will be offering website SSL certificates and providing a minimal automated
email ping verification of the site administrator.
FreeCert routes will be available for download from the FreeCert.org website.
Users can import them into their browsers and have the option to trust them or to review
certificates on a case-by-case basis.
FreeCert routes will not be automatically trusted by your browser.
This is how all browser route certificates should be, however.
The user should have to go into the browser and specify which routes he's willing to blindly
trust.
There shouldn't be any routes in there that are, by default, trusted.
The desired outcome of this project, if it is successful, will be to make web users accustomed
to approving or denying individual site certificates.
They're going to see these error messages.
A lot, if FreeCert's usage is wide spread.
They're no longer going to find, these warning messages, terrifying.
And they're not going to stop their browsing because of it.
The large majority of users will probably, and already probably do, just click the OK
button and go through.
But, ones that are concerned by this, should go in and examine every certificate that they
encountered for the first time.
And choose to trust it ... or not.
3.
We wish to increase the number of SSL-secured websites
on the internet.
Pre-cert is not competition for VeriSign.
Instead, we're competing against the unsecured web.
I spent a little bit of time today
criticizing commercial CAs.
I'd like to state that most of my complaints
are with regard to the use of CAs
for web service certificates.
Other applications, such as client browser certificates,
access controls, attribute certs, and so on,
could definitely warrant the use
of a trusted certificate authority.
Initially, Pre-cert will not be doing anything in that area.
We don't have the ability
to do the level verification necessary.
For those of you who are interested,
Pre-cert is looking for volunteers.
If you have experience in project management,
website development, shell scripting,
feel free to email me at rabbi at pre-cert.org.
For information on how you can help.
I could continue talking now about
the technology behind Pre-cert itself,
about the SSL process,
or about CA procedures...
Umm...
...but I don't have time to do all three,
so I'd like to turn it over to questions
and see what the audience wants to hear.
Does anyone have any questions for me?
So, my understanding is that SSL,
Correct.
Well, it's a combination of public key and symmetric key.
Your public key to encrypt back to you so that now you can use your private key to decode it.
The same process that happens with certificates for secure email?
Right.
It works both ways, though.
When you're submitting to the web server, you're encrypting to the web server's public key.
That's...
How does that process happen when you install ID5 that has a unique public and private key
that it generates?
Is this a random process?
It would be a random key that's generated for your browser.
You can also request client certificates.
I don't really want to go into that too much here because that's not in the scope of FreeCert,
but the same process that happens for the web server you can do for your client server
and use your client certificate in lieu of a password for some sites.
Is there any way without...
without somebody having your private key to alter an encrypted transmission
and it's still not to be complete garbage at the other end?
For instance, if it was a message that said,
buy 100 shares, is there any way for you to change that message
to say anything else than that without just being garbage at the other end?
Generally, no.
There is...
I'd say it's strong encryption.
Excuse me.
I got it.
128-bit, something like that.
I'm just wondering why they go through the trouble of message digest.
Right.
The information being sent is signed as well.
So if you're submitting the information, you have...
Okay, so the scenario here is you have a web server
that's got a legitimate certificate,
and you've got your client there,
and you do a key exchange,
and you set up encrypted to the public key,
and you do a key exchange,
So they have those keys,
is a key for symmetric key.
Symmetric cryptography
is far faster than public keys.
So the actual data that's transmitted
is all symmetric key.
What do they have together with the keys?
One thing about those keys,
they set up the shared secret,
and then information is encrypted using a stream cipher
or a symmetric cipher,
and that information is transmitted
between the...
from the dot line,
client and the server.
Would it be binary or ASCII?
Would you see ASCII character?
Did you see binary junk?
Correct.
I believe it's binary.
It's...
It possibly could be ASCII, but I'm not 100% certain on that.
But you can't...
You're not gonna be able to go in unless there's a flaw in the encryption algorithms you're
using and alter that.
Okay.
Thank you.
Sure.
I had a question about the CRLs.
What is a protocol?
Is it a protocol shortfall on ?
Yes.
The question is CRLs.
Is it a protocol shortfall in SSL?
or is it that most browsers haven't implemented CRL checking? It's pretty much both. And it's
largely a lack of a comprehensive collection of certificates and a decent mechanism of pushing
them out to the browsers. There are some protocols, OCSP, that attempt to fix this, but they are
not perfect and they are not entirely reliable. Free cert will have certificate revocation
lists, but there's the same problems that exist everywhere. We won't be solving any of these
certificate revocation issues. If you're concerned, you can go and get the certificate revocation
list. Most users don't do that. That's the problem.
Here.
Something that I've been trying to do personally is verify fingerprints of web server certificates
and CA certificates. And I was wondering if you had any comments on those or verifying
them.
Oh, boy. Now I'm going to pick on thought again. So what Russell said here was he's
been looking at verifying fingerprints of server certificates.
And CA, root certificates. The fingerprint is a hash of the certificate, basically.
And it's a hash is a mathematical calculation that gives you a unique or unforgeable smaller
string of numbers that correlates to the data you pass through that procedure. The point of a secure
hash is that you can't find a desired outcome of numbers by specifying the numbers you're
putting, the information you're putting in. It's a one-way function.
So these are used to generate fingerprints on keys, which allow you to very easily confirm
that you have a valid key. We could conceivably read off all the numbers in the key, but that
would take a long time. The way to actually check and make sure that you've got legitimate
numbers in your certificate, regardless of the CA, is to confirm with the person who actually
is authorized to have the certificate what the fingerprint for that certificate is.
Now, I don't suppose you can go to eBay and click a button that says, here's our web
server certificate fingerprint. And I wouldn't really expect the individual sites to be doing
this. But the CAs who are in the business of trust should have a mechanism to verify their
certificates. As I said, a compromise of a root certificate compromises all the certificates
issued by that root, not just the one service certificate. A friend of mine called up Thot a few
years ago. He made a long-distance call to South Africa, and he said he wanted to verify their
fingerprint of their root keys. They didn't know what a fingerprint was. I think that's all I have
to say on that.
I might call it an MD. I mean, they might call it an MD.
He explained that they call it thumbprint in some browsers. They call it message digest.
They finally got the idea eventually, and then they said we're not authorized to give that
information out. But you shouldn't have to make a call to the CA. There should be sections of
their website that have this information. Now, of course, if their website is compromised, that
information isn't trustworthy, but there should be mechanisms for users to verify this.
That's something that we'll definitely be doing. And in fact, I've also been thinking about
keeping a list of the fingerprints and fingerprints tying to URLs of certificates we issue.
So if you wanted to go to our website and verify a fingerprint, you could pull up a list of
the certificates we've issued. It'll show whether it's expired or revoked or not, the URL and the
certificate. Yes?
Would you be able to exclude that fingerprint as a core root certificate, build an illegitimate
site certificate, and then match it to the URL?
No, you can't. The reason fingerprints are used is you can't work backwards. You can't take a
fingerprint and say, okay, now I want to generate a key that matches up with this. If you can do
that, then that's a cryptographic attack against the message digest algorithm. And there are severe
problems with it.
Not secure hashes all day long?
Not secure hashes.
I think the point here that it's getting to is the point is that two of these message digests are
made. Two of these one-way encryptions are made.
Okay.
The encryption coming over and then another print that's not encrypted. And so somebody, if I've got this
right, if somebody tries to alter one of them, then the two don't match. And when the two don't match,
then there's a problem. They're both one-way encrypted. You're not giving away what the message
was.
Well, actually, what I was just talking about was the fingerprint of the certificates.
It's the fingerprint itself, not the actual transmission. You have a certificate. You pass it through the hash.
You get the fingerprint. You can't work with a fingerprint and move backwards and get a
certificate that matches up with it. The only way to do that is a brute force attack where you basically
generate hundreds and thousands of certificates and look for one that matches. And that will take a long
time.
Yes?
.
.
.
.
Right. They are not cryptographic problems.
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Right. I'm not addressing cryptographic problems here at all.
It is largely an education issue.
And that's what FreeCert really is.
It's an education project.
We are going to be throwing these untrusted site certificates out there,
and it's going to make users question what exactly is happening here.
We will have explanations on our website.
And hopefully users will become more educated
as they encounter more of these certificates.
Sure. I suspect most of the client sites will want to put a small message saying,
for information about our security, go here and come to our site.
But yes, that would be good.
So, supposing that you educate people to check out the search, what do they check?
I mean, in the end, you trust something electronically out there.
You trust something, yes.
And you have to, it's up to the user to make,
my whole point here is it's up to the user to make that decision.
It should not be up to a browser, which is,
browsers are distributed from non-trusted sources.
You don't download a PDF.
You don't download a PDF signature with the browser and verify that the browser hasn't been tampered with.
These decisions are being made for the users
without their understanding of what exactly is being decided for them.
So, yes, you have to place your trust in something,
and there is not total security here.
Unless you go and talk to the IT administrator of...
Well, let's be clear with that.
What's so bad about...
I dislike Microsoft as much as the next...
What's so bad about, let's just put FreeCert as one of the,
as the 110th list on the list of Microsoft?
I mean, you really don't...
Because...
So you're asking...
You're asking why I wouldn't go and get FreeCert's roots put into the browser
and just become another blindly trusted CA.
That's the entire issue I'm trying to fight against here.
We don't need another blindly trusted CA.
All I'd be doing was providing free certificates out.
And we're really not doing enough identity verification to warrant that.
The way we're constructing things,
we're basically sending out an email ping
similar to a lot of mailing the software does
to the technical contact of the site.
And if it comes back valid, we'll issue the certificate.
That's the initial first untrusted level
we'll be scaling up as we have more staff.
But what we really want to do is make users aware of what's happening here.
Even if they can't make the intelligent decision that this is trusted or not,
they at least know that there's that risk.
A lot of them right now aren't aware that there is a risk
that they might be sending stuff to the wrong site.
But again, the probability of an attack being executed
against a site's certificate and being spoofed
is very slim.
What really is important is the...
The chances that you're going to be encrypting to the wrong website are minimal.
So I want to encourage these certificates
on places where certificates aren't already being used.
Let me get one in the back here.
There's somebody waving their hand.
No? Okay.
Okay.
Okay.
Is Chris Ricks in the audience?
We have a...
Chris Ricks?
Ricks.
Ricks?
Okay.
Any other questions?
Any other questions?
Yeah.
Can people realize that it really gives them the trust
when they're associating?
When they're associating with the right thing?
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
You can call me up and confirm fingerprints.
But, yeah.
What you do is you...
With the trust model here,
you keep narrowing and narrowing
the probability that you're going to be able to do something.
of attack, but you never get that probability down to zero.
There is no such thing as total security.
Yes. And a probability
of authenticity, but not an assurance.
Yeah, two things.
First is, what would you recommend?
So, you're basically messing with people. So, you're popping up a search
that says, do you want to accept this certificate? What would you recommend that people
do to verify a certificate? So, they first have
to weigh the value of the information they're submitting.
Use your American Express card on the internet.
You're not responsible for fraud. So, if your
number is stolen when you're submitting it, there's no out-of-pocket
expense for the
user. And most other credit cards, it's a $50
you're responsible for the first $50, and then the rest is eaten by the credit card company.
So, if they decide that, okay, the stuff I'm
submitting here is super secret, and I need to
be sure that the site I'm submitting to is the correct site,
what I would do is, the best
way would be to locate the number,
for the website you sent it to the company, and talk to someone in their IT department and
find out the fingerprint.
He's saying that the information he's submitting, it can absolutely not go to the wrong people.
I understand, I mean, security is fundamentally risk-managed.
Right.
So, I know, I can only accept this much risk. How do I determine how much risk I'm taking by clicking accept?
What metric do I use to determine, so, how much risk is taken by clicking accept?
how risky this transaction is, to measure that against how important my data is.
Well, that is a decision that has to be made by the user.
I mean, I can't tell you what your metric is.
I would...
But what can you do to get that information?
You can call them up.
You can examine, do an examination of the information that's embedded in the certificate
and see if it, you know, sanity check it.
If this is a company registered in Russia and it's supposed to be a U.S. e-commerce company,
that's a red flag.
It's all basically whether or not this looks legitimate.
And it's very subjective.
And the second thing is, would you talk about the software you're using to deploy this?
We are using OpenSSL.
And we have some modifications.
We have some modifications to it.
We have, for our key management devices, we're using an N-Cypher secure key management hardware device.
And this is all in Sun hardware.
In the back there.
Thank you.
This is all being done by a series of volunteers right now
who are donating their time, their bandwidth, and their hardware.
We have, we're working with the Shmoo Group and the Crypto Rights Foundation as well.
Yes.
We're asking, do you want any more volunteers on the software side or do you want to go back to the base?
Yeah, right now it's all, it's all volunteer donations.
And the free certificates are the ones that are the low level e-mail paying verification.
If we end up having the ability and resources to start doing more in-depth verifications,
we will probably be charging a minimal fee and that will go back into funding our resources.
Your website is?
Freecert.org.
Yes.
Do you have time or desire to talk about personal certificates?
Let me see if there's any other questions about service certificates.
I can talk briefly about personal certificates.
But that doesn't, that's really not what I've been addressing today.
But I will talk about that if there's interest.
Are there any other? Yes.
Just in general.
Suppose we wanted to run an internal C.A.
but we didn't want to go by an organization or certificate from the software side or something else like that.
Are there any open source options?
Or will Freecert ever allow you to do organizational web or something like that?
So you're talking about an internal?
Yes.
Just kind of based on a PKI option.
For an internal PKI, you don't need a C.A. at all.
You become your own C.A.
Because I assume you're talking about your quote unquote customers are your employees.
Right.
Right.
You don't need an external C.A.
The external C.A. is basically for use on the internet at large.
If you are setting up an internal PKI, you generate your own route with the software you have, encryption software.
There are some open source software solutions out there that are difficult to set up and configure.
And there's some low cost commercial PKI systems and some more expensive PKI systems.
You generate your own route.
And you push that out to the browsers of your employees.
And then that's trusted.
And you can extend that off.
It doesn't have to be just website browsing.
You can use that for client certificates.
You can use that for access controls to your VPN and your IPsec applications, et cetera.
Do you have links or any other information about the open source?
Our website is very minimal right now.
We're looking for more volunteers.
We intend to have.
We have a whole education system where we'll provide information and assistance to companies that want to go about setting up something like that.
Thank you.
There was somebody in the back there who had a question.
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Okay. If it's in their way of getting something, they just say yes.
True. There are a lot of people that would just say yes
even with any warnings whatsoever. I'm not sure exactly
what your question is.
Your certificates, if they're not from a trusted authority,
do you follow the message? That's done by the browser.
In the new operating system for Microsoft, the browser settings
are set to I. I think it's 128 minimum
now. So if it's not a signed certificate
If it's not a signed certificate from a trusted root,
it's going to warn you that it's not a trusted...
Exactly. It'll pop up.
In what OS?
That, to my knowledge, is incorrect. I don't know about
XP, but Windows 2000 and ME still warn you
if you're not using a trusted... if it doesn't
originate from a trusted root.
Anyone else?
You still get a warning if it's not trusted.
Right.
I think we're...
I think we have time for a few more questions.
Anyone?
Okay. If anyone wants to see me afterwards to talk about
any of this in more detail, they can feel free to find me.
Or you can email me, rabbi at freesert.org.
Yeah.
So next up we have Dario Diaz.
